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La presente invention se rapporte a un procede et a un dispositif de 
5 gestion de requetes dans une architecture du type client-serveur. 

Depuis ces dernieres annees, le grand public a la possibility 
d'echanger des donnees numeriques a travers le reseau Internet. Plus qu'un 
phenomene de mode, Internet est devenu un outil sans precedent pour envoyer 
un message electronique et/ou obtenir des informations sur a peu pres 
10 n'importe quel sujet et ce quasiment en temps reel. Les premiers sites, 
communement appeles sites Web, permettaient de telecharger une application 
(ou une page au format HTML), et de la "jouer" (ou de la visualiser a partir d'un 
outil de navigation). 

De nombreuses evolutions ont ete apportees tant au niveau des 
• 15 formats de fichiers transferes qu'au niveau des protocoles de transfer! 

Concernant plus specifiquement le format de fichier HTML, les pages Web sont 
devenues interactives, permettant ainsi a I'utilisateur de personnaliser la 
visualisation de ces pages et d'envoyer des requetes au serveur qui heberge le 
site visite. De plus, ces pages sont devenues plus attrayantes depuis que ce 
20 . format permet ^encapsulation d'animations temporelles d'objets multimedia. 

Neanmoins, la taille des fichiers transferes, c'est-a-dire les fichiers 
qui contiennent une application ou une page HTML, doit etre minimale car la 
bande passante du reseau Internet est toujours limitee a quelques kilo octets. 
De Tagon que le temps de telechargement ne soit pas trap important, le format 
25 HTML a ete con?u pour permettre d'organiser de fa?on hierarchique les 
donnees a transferer. Ainsi, en hierarchisant ces donnees selon leur ordre 
d'utilisation par I'outil de navigation, il est possible de visualiser une page HTML 
ou de jouer une animation sans pour cela attendre que tout le fichier soit 
telecharge. Cette propriete permet a I'utiiisateur de naviguer plus aisement sur 
30 un site. 

Pour les animations d'objets multimedia, un format de fichiers (SWF) 
a ete defini qui permet de decrire des animations temporelles de donnees 
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multimedia a partir de donnees vectorielles. Airisi, la taille des fichiers HTML 
reste dans des proportions acceptables. De plus, ce format permet de jouer 
('animation sans pour cela attendre que Pensembie du fichier soit telecharge. 
Pour ces deux raisons, ce format est largement utilise pour inclure des 
animations d'objets multimedia dans une page HTML et on commence a voir 
apparaitre des sites congus exclusivement avec des donnees "Flash" (nom 
communement employe pour designer des animations resultant d'un fichier 
SWF). 

Des qu'un utilisateur demande le telechargement de donnees 
multimedia a un serveur, ce dernier lui envoie un fichier qui comporte des 
donnees dites minimales. A partir de ces donnees, Poutil de navigation construit 
une page HTML et la visualise sur un ecran. Dans le cas ou cette page 
contiendrait une animation Flash, les donnees dediees a cette animation sont 
interpretees par un "decodeur" Flash integre a Poutil de navigation. 

Le fichier de donnees peut egalement comporter un jeu de 
commandes qui permettent de recuperer des donnees multimedia 
supplemehtaires, une fois que le fichier est telecharge. De plus, dans la plupart 
des applications, les donnees minimales permettent a I'utilisateur d'interagir 
avec le serveur pour pouvoir recuperer des informations supplementaires. C'est 
ce qu'on appellera par la suite des "requetes". 

Comme on le verra plus loin, la presente invention peut s'appliquer a 
n'importe quel systeme de reception de donnees multimedia qui inclut des 
requetes d'origines differentes. 

De fa?on generate, les requetes sont de natures differentes. Elles 
peuvent etre predictibles, dans le cas ou elles seraient incluses dans le fichier 
telecharge initialement et que les donnees recuperees, au travers de ces 
requetes, sont necessaires au bon deroulement d'une application (ou d'une 
animation). Ce jeu de requetes est predefini par le concepteur de Papplication 
ou de I'animation. D T autres sont impredictibles, telles que les requetes emises 
par I'utilisateur. Enfin, une derniere classe de requetes permet d'anticiper le 
pre-chargement (en anglais "pre-fetching") de donnees multimedia. En effet, 
des lors qu'un utilisateur a telecharge un fichier, on peut anticiper les futures 
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demandes de cet utilisateur et pre-charger des donnees, de fagon a repondre 
sans delai a ces besoins futurs. Ces requetes ne sont generalement pas 
predictibles, car elles evoluent selon les requetes effectives de I'utilisateur et ie 
deroulement de I'application (ou de I'animation). 
5 La plupart des systemes de transmission de donnees multimedia ne 

sont pas confrontes au probleme de gestion de requetes de natures differentes 
car le format des donnees encapsulees dans le fichier ne fournit pas la 
possibility de definir des requetes de natures differentes. Seules les requetes 
emanant de I'utilisateur sont gerees et parfois celles liees a I'application. 
10 Neanmoins, ces systemes ne gerent pas plusieurs classes de requetes a la 
fois. 

Le document US-A-6 442 658 divulgue un mecanisrne qui gere un 
jeu de requetes de fagon qu'une animation Flash puisse se derouler 
correctement. 

15 Le fichier SWF utilise pour definir une animation Flash est 

decompose en segments de donnees independants les uns des autres. Par 
exemple, un premier segment comporte des donnees video et un second 
segment des donnees image. Lorsque la machine client regoit le premier 
segment, le "decodeur" Flash doit s'assurer que les ressources necessaires 

20 pour jouer la video, c'est-a-dire la memoire disponible et le decodeur de 
donnees video, dans le cas ou les donnees du segment seraient codees,. sont 
disponibles sur la machine client. Si le decodeur est present sur la machine 
client, le segment est joue. Dans le cas contraire, le "decodeur" Flash extrait la 
localisation de cette ressource a partir du fichier SWF - le plus souvent un lien 

25 Internet sur un serveur - et envoie la requete a ce serveur. Une fois la reponse 
regue, le decodeur video est installe sur la machine client et le segment est 
joue. 

Ainsi, si plusieurs segments doivent etre joues, la solution la plus 
triviale est de verifier si toutes les ressources necessaires pour jouer les 
30 segments d'un fichier SWF sont disponibles sur la machine client. Dans le cas 
ou certaines d'entre elles ne le seraient pas, il faut emettre des requetes aux 
differents serveurs au travers des informations extraites a partir du fichier SWF. 
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Neanmoins, cette solution n'est pas envisageable car elle 
demanderait trop de memoire de stockage et des temps de telechargement trop 
importants avant de pouvoir jouer le premier segment. Le document US-A-6 
442 658 propose de resoudre ce probleme en incluant un mecanisme de pre- 
5 chargement de ces ressources. En effet, lorsqu'un segment est en train d'etre 
joue, ce processus telecharge les donnees et les ressources du segment qui va 
etre joue juste apres. Une fois jouees, les donnees et les ressources sont 
supprimees de la memoire de stockage, evitant ainsi une surcharge de cette 
memoire. 

10 Le probleme resolu par ce document consiste done a definir le 

segment qui sera joue a la fin de I'execution du segment courant. Pour cela, 
une priorite est associee a chaque segment. Cette priorite est la combinaison 
du temps necessaire a la recuperation des donnees et des ressources et de la 
probability que le segment soit joue juste apres le segment courant. 

15 Le mecanisme decrit dans ce document ne gere qu'une seule classe 

de requetes de pre-chargement. De plus, le jeu de requetes considere dans ce 
document est statique, e'est-a-dire qu'aucune nouvelle requete de pre- 
chargement n'est engendree. 

La presente invention a pour but de remedier a cet inconvenient, en 

20 permettant de gerer les requetes de differentes classes et d'engendrer de 
nouvelles requetes de pre-chargement au cours de I'execution d'une application 
et en fonction du comportement de I'utilisateur. 

Dans ce but, la presente invention propose un procede de gestion de 
requetes d'au moins deux classes distinctes, portant sur des donnees 

25 multimedia, echangees par un appareil de communication et au moins une 
source ' de donnees connectes par 1'intermediaire d'un reseau de 
communication, remarquable en ce que ce procede comporte des etapes, 
effectuees au niveau de I'appareil de communication, de : 

- validation d'au moins une requete d'au moins une premiere classe 

30 de requetes, la validation tenant compte des donnees multimedia recues a 
partir d'au moins une deuxieme classe de requetes ; et 
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- affectation dynamique d'une priorite a chacune des requetes 
validees, suivant des caracteristiques des requetes validees. 

L'invention permet ainsi, grace a ('attribution de priorites aux diverses 
requetes, de gerer des requetes de differentes classes. 
5 L'etape de validation permet d'autoriser (ou non) momentanement 

renvoi de chacune des requetes. 

L'etape d'affectation dynamique permet de hierarchtser les requetes 
validees, de fagon a recuperer les donnees les plus utiles a un instant donne. 

Selon une caracteristique particuliere, le procede comporte en outre 
10 une etape de decision quant a la transmission d'au moins une requete validee, 
en fonction de la priorite affectee a cette requete. 

Cela permet de gerer renvoi en continu des requetes, de fagon a 
optimiser 1'utilisation de la bande passante du reseau. . 

Selon une caracteristique particuliere, ce procede comporte en outre 
15 une etape de mise a jour des requetes d'au moins une premiere classe, la mise . 
a jour tenant compte des donnees multimedia revues a partir d f au moins une 
requete d'au moins une deuxieme classe. 

En reponse a ces requetes, des donnees sont regues et 
memorisees. L'analyse de ces donnees rend obsoletes certaines requites, 
20 puisque les donnees sont deja recuperees. Par ailleurs, de nouvelles requetes 
peuvent etre creees car de nouveaux besoins peuvent emaner de la part de 
I'utilisateur au travers d'une interface graphique. Enfin, selon les donnees 
regues, certaines requetes doivent etre fusionnees, car considerees 
individuellement, elles ne permettent de recuperer qu'une infime partie des 
25 donnees. Comme chaque requete possede un entete incompressible, il peut 
arriver que la quantite de donnees recuperees soit tres faible par rapport a la 
taifie des requetes. Cette fusion de requetes permet ainsi d'optimiser la bande 
passante du reseau en minimisant renvoi de requetes. L'etape de mise a jour 
permet la gestion de ces differents cas. 
30 Dans un mode particulier de realisation, I'appareil de communication 

et la source de donnees sont connectes par une connexion de type HTTP. 
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Les donnees peuvent par exemple etre des animations Flash et/ou 
des donnees d'images comprimees suivant la norme JPEG2000. 

Les requetes peuvent etre associees a Tanimation d'un objet et/ou a 
la realisation d'un zoom ou d'un panoramique ou d'un changement de qualite 
5 sur une image et/ou a des interactions entre un utilisateur et une animation. 

Dans le meme but que celui indique plus haut, la presente invention 
propose egalement un dispositif de gestion de requetes d'au moins deux 
classes distinctes, portant sur des donnees multimedia, echangees par un 
appareil de communication et au moins une source de donnees connectes par 
10 I'intermediaire d'un reseau de communication, remarquable en ce que ce 
dispositif comporte : 

- un module de validation d'au moins une requete d'au moins une 
premiere classe de requetes, la validation tenant compte des donnees 
multimedia re?ues a partird'au moins une deuxieme classe de requetes ; et 

15 - un module d'affectation dynamique d r une priorite a chacune des 

requetes validees, suivant des caracteristiques des requetes validees. 

La presente invention vise aussi un appareil de communication 
comportant un dispositif tel que ci-dessus. 
L'invention vise aussi : 
20 - un moyen de stockage d'informations lisible par un ordinateur ou 

un microprocesseur conservant des instructions d'un programme informatique, 
permettant la mise en oeuvre d'un procede tel que ci-dessus, et 

- un moyen de stockage d'informations amovible, partiellement ou 
totalement, lisible par un ordinateur ou un microprocesseur conservant des 

25 instructions d'un programme informatique, permettant la mise en oeuvre d'un 
procede tel que ci-dessus. 

L'invention vise aussi un produit programme d'ordinateur po.uvant 
etre charge dans un appareil programmable et comportant des sequences 
destructions pour mettre en oeuvre un procede tel que ci-dessus, lorsque ce 
30 programme est charge et execute par Tappareil programmable. 

Les caracteristiques particulieres et les avantages du dispositif de 
gestion de requetes, de Pappareil de communication, des differents moyens de 
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stockage et du produit programme d'ordinateur etant simiiaires a ceux du 
procede selon I'invention, ils ne sont pas rappeles ici. 

D'autres aspects et avantages de 1'invention apparattront a la lecture 
de la description detaillee qui suit de modes particuliers de realisation, donnes a- 
5 titre d'exemple non limitatif. La description se refere aux dessins qui 
I'accompagnent, dans lesquels : 

- la figure 1 illustre de fa?on schematique un dispositif de 
transmission de donnees multimedia mettant en oeuvre la presente invention, 
dans un mode particulier de realisation ; 

10 - la figure 2a illustre de fa?on schematique un exempie d'animation 

Flash ; 

- la figure 2b illustre de fa?on schematique des exemples d'actions 
sur une image au format JPEG2000 ; ^ 

- la figure 3 est un organigramme ilfustrant les principales etapes 
' 15 d'initialisation du mecanisme de gestion des requetes conforme a la presente 

invention, dans un mode particulier de realisation ; 

- la figure 4 est un organigramme illustrant les principales etapes de 
la mise a jour du jeu de requetes de pre-chargement conformement aJa 
presente invention, dans un mode particulier de realisation ; 

20 - la figure 5 est un organigramme illustrant les principales etapes du 

mecanisme d'envoi des requetes conformement a la presente invention,. dans 
un mode particulier de realisation ; et 

- la figure 6 illustre schematiquement un dispositif mettant en ceuvre 
la presente invention, dans un mode particulier de realisation. 

25 Le schema-bloc de la figure 1 illustre ['architecture .generate d'un 

dispositif de transmission de donnees numeriques point a point entre une 
machine dite serveur et une machine dite client, mettant en ceuvre I'invention. 

Ce dispositif peut comporter des elements electroniques et/ou 
comporter des elements logiciels. 

30 Le dispositif represents sur la figure 1 comprend une machine 2 dite 

client, qui est un appareil de communication, et une machine 1 dite serveur, qui 
constitue une source de donnees. Ces machines sont reliees par un reseau de 
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communication 3 au travers d'une connexion. Selon un mode prefere de 
realisation de ('invention, une connexion HTTP est utilisee. Neanmoins, 
I'invention peut etre mise en oeuvre sur d'autres types de connexions. La 
machine client 2 peut, en variante, etre reliee a plusieurs sources de donnees 
5 du type de la machine serveur 1. De plus, nous considerons par la suite que la 
transmission des donnees s'effectue sans aucune perte d'information. 

La machine client 2 de la figure 1 comporte une unite 21 de stockage 
de donnees numeriques qui memorise temporairement les donnees 
numeriques regues. Une unite 22 de stockage de requetes memorise quant a 

10 elle, a la fois les requetes regues par une unite 24 de reception de requetes, et 
les requetes emanant d'une unite 26 de gestion de requetes, comme on le 
verra par la suite. L'unite 26 de gestion de requetes est au coeur de I'invention. 
Le client 2 comporte aussi une unite 25 d'envoi de requetes. 

La machine client 2 comporte egalement une unite 27 de reception 

15 de donnees numeriques, dont le role est de recevoir les donnees numeriques 
emanant du serveur 1 et de les envoyer a I'unite 21 de stockage de donnees. 
De plus, la machine client 2 comporte une unite 23 de traitement de donnees 
numeriques qui traite les donnees numeriques stockees dans I'unite 21. Selon 
un mode prefere de realisation de ['invention, I'unite 23 de traitement de 

20 donnees prepare les donnees contenues dans I'unite 21 de stockage pour les 
visualiser sur'un ecran (non represents sur la figure 1). 

Enfin, la machine client 2 comporte une unite 28 de commande qui 
controle le fonctionnement des diverses unites mentionnees precedemment. 

La machine serveur 1 de la figure 1 comporte une unite 10 de 

25 reception de requetes, qui receptionne les requetes emanant de la machine 
client 2. L'unite 10 de reception de requetes envoie les requetes a une unite 12 
de traitement de requetes, qui les traite. Selon un mode prefere de realisation 
de I'invention, ce traitement consiste a recuperer les -donnees numeriques 
requises, a partir d'une unite 13 de stockage de donnees numeriques, et a les 

30 formater et les envoyer au travers d'une unite 11 d'envoi de donnees 
numeriques. La machine serveur 1 comporte egalement une unite 14 de 
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commande qui controle le fonctionnement des diverses unites mentionnees 
precedemment. 

Selon un mode prefere de realisation de 1'invention, une connexion 
HTTP est etablie entre les machines client 2 et serveur 1. Pour cela, les unites 
5 25 d'envoi de requetes et 27 de reception de donnees de la machine client 2 et 
les unites 10 de reception de requetes et 1 1 d'envoi de donnees de la machine 
serveur 1 implemented ce protocole, de fagon a pouvoir echanger des 
donnees. 

Selon un mode prefere de realisation de ('invention, les donnees 

10 numeriques echangees sont de deux natures : des animations Flash et/ou des 
donnees d'image comprimees suivant la norme JPEG2000. 

Les animations Flash sont stockees dans des fichiers ayant une 
extension n .swf\ Par la suite, ce type de fichiers sera appele SWF. Qes 
animations sont largement utilisees a I'interieur des pages Web et meme p9ur 

15 definir completement un site. De par leur format vectoriel, elles permettent 
introduction d'animations temporelles d'objets numeriques dans les pages d'un 
site Web et ce tout en preservant une tailie du fichier SWF reduite. 

Par la suite, nous considerons qu'une animation a ete creee et 
stockee dans i'unite 13 de stockage de donnees de la machine serveur 1. . 

20 . * En reference a la figure 2a, le fichier SWF 205 utilise par la suite 

contient une animation temporelle d'un objet, c'est-a-dire des donnees d'image 
representant I'objet lors de sa position initiale 201 jusqu'a sa position finale 202 
selon la trajectoire 203, ainsi qu'un jeu de requetes permettant de recuperer, a 
partir du serveur, des informations complementaires necessaires a la realisation 

25 de I'animation. Les requetes associees a Tanimation de cet objet composent 
une classe de requetes appelee par la suite Ra. 

De plus, le fichier SWF contient une image 204 comprimee suivant le 
format JPEG2000. Ce format permet un acces aleatoire aux donnees image, 
c'est-a-dire que le train binaire est formate de fa?on a pouvoir recuperer 

30 plusieurs resolutions spatiales de I'image pour une meme qualite et plusieurs 
qualites pour une resolution spatiale donnee. De meme, il est possible de 
recuperer une partie de I'image a une qualite donnee. Le fichier JPEG2000 est 
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stocke dans I'unite 13 de stockage de donnees de la machine serveur 1. Selon 
un mode prefere de realisation de I'invention, la version basse qualite de 
I'image est incluse dans le fichier SWF. 

Lorsque ('animation Flash est jouee, I'utilisateur a la possibility 
5 d'effectuer des actions sur I'image JPEG2000 telles que decrites par la figure 
2b. Selon un mode prefere de realisation de I'invention, trois actions sont 
disponibles : un zoom, un panoramique (en anglais "pan") (dans le cas ou la 
fenetre de visualisation 207 de I'animation serait plus petite que I'image 206 a 
visualiser) et un changement de qualite : basse, moyenne et haute. 

10 Afin d'anticiper ces actions et done d'ameliorer I'interactivite entre 

I'utilisateur et ('animation, des requetes de pre-chargement sont incluses dans 
le fichier SWF. Ces requetes composent une classe de requetes appelees par 
la suite Rpl. Elles permettent d'obtenir les donnees image permettant 
d'effectuer un zoom et un panoramique dans chaque direction pour une qualite 

15 basse. On peut noter que si I'image incluse dans le fichier SWF a une qualite 
autre (moyenne ou haute), ces requetes seront definies en fonction de ce choix. 
On parlera alors respectivement de classes de requetes Rpm et Rph. Par la 
suite, la classe Rp sera aussi employee. Cette classe regroupe les requetes 
des classes Rpl, Rpm et Rph. 

20 Comme on Pa deja mentionne, I'utilisateur peut interagir avec 

I'animation en demandant un zoom sur une partie de I'image, un changement 
de qualite ou un panoramique selon une direction. Ces actions sont transcrites 
sous forme de requetes qui composent une classe de requetes appelees par la 
suite Ru. 

25 En resume, trois classes de requetes sont potentiellement presentes 

sur la machine client 2 : Ra, Rp et Ru. Les requetes de ces trois classes ont un 
caractere different : 

- les requetes de la classe Ra evoluent temporellement et sont 
predictibles. Elles sont optionnelles car un fichier SWF qui ne contiendrait que 

30 des images JPEG2000 n'aurait pas besoin de ce type de requetes ; 

- les requetes de la classe Rp sont predictibles, dans le sens ou un 
jeu de requetes est inclus dans le fichier SWF. On peut egalement noter que 
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ces requetes evoluent selon les actions de I'utilisateur. En effet, en revenant a 
notre exemple, si I'utilisateur modifie la qualite de I'image, le jeu de requetes 
Rpl devient obsolete et un nouveau jeu Rpm (par exemple) doit etre engendre 
de fagon que les donnees image recuperees aient la meme qualite que I'image 
5 visualisee. Ce type de requetes est optionnel car on peut creer un fichier SWF 
sans pour cela prevoir des requetes de pre-chargement (c'est actuellement le 
cas des outils d'edition d'animations Flash) ;■ 

- les requetes Ru sont impredictibles. Ce type de requetes est 
egalement optionnel car une animation peut ne pas autoriser d'interactions 

10 avec un utilisateur. 

L'organigramme de la figure 3 illustre la phase d'initialisation du 
dispositif de la figure 1. Une fois que I'utilisateur a etabli une connexion avec la 
machine serveur 1 de la figure 1, I'unite 25 d'envoi de requetes de la machine 
client 2 est reliee a I'unite 10 de reception de requetes de la machine serveur 1 , 

15 de fagon que le serveur puisse recevoir des requetes de la part du client De 
meme, I'unite 11 d'envoi de donnees de la. machine serveur 1 est reliee a I'unite 
27 de reception de donnees de la machine client 2, de fagon que la machine 
serveur puisse envoyer des donnees numeriques a la machine client. Des que 
la machine client demande une animation, au travers de I'unite 25 d'envoi de 

20 . requetes, la machine serveur receptionne cette' requete au travers de I'unite 10 
de reception de requetes et recupere le fichier SWF a envoyer a partir de ['unite 
13 de stockage de donnees. Ce fichier est envoye au travers de I'unite 11 
d'envoi de donnees. 

La machine client 2 receptionne ce fichier a partir de I'unite 27 de 

25 reception de donnees et le stocke dans I'unite 21 de stockage de donnees 
(etape E300). De plus, au cours de cette etape, la machine client 2 initialise une 
liste L qui contiendra des elements E, relatifs a chaque requete stockee dans 
I'unite 22 de stockage de requetes, et ce quelle que soit la classe a laquelle la 
requete appartient Chaque element E de cette liste est memorise dans I'unite 

30 22. II contient une reference identifiant la requete, une variable C representant 
sa classe, une variable P definissant sa priorite et une variable binaire W qui 
vaut 1 si la requete est valide et 0 sinon. 
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L'etape E300 est suivie d'une etape E301 au cours de laqueile la 
machine client 2 extrait les donnees image JPEG2000 du fichier SWF et tes 
stocke dans I'unite 21 de stockage de donnees. De plus, la qualite Q de I'image 
JPEG2000 recuperee est memorisee dans I'unite 21. 
5 L'etape E301 est suivie d'un test E302 au cours duquel la machine 

client 2 teste si le fichier SWF contient des requetes de la classe Rp, c'est-a- 
dire des requetes de pre-chargement, que ces requetes soient du type Rpl 
(associees a Pimage basse qualite), Rpm (hnoyenne qualite) et/ou Rph (haute 
qualite). Selon un mode prefere de realisation de I'invention, seules des 

10 requetes de la classe Rpl sont presentes. Si le test E302 est negatif, il est suivi 
d'un test E308 decrit ulterieurement 

Si le test E302.est positif, la machine client 2 extrait : ces requetes du 
fichier SWF et les stocke dans i'unite 22 de stockage de requetes (etape E303). 
De plus, pour chacune des requetes extraites, la machine client 2 cree un 

15 nouvel element E de la liste L. 

L'etape E303 est suivie d'une etape E304 au cours de laqueile la 
machine client 2 recupere la qualite Q stockee dans I'unite 21 de stockage de 
donnees et initialise les variables W et C de chacun des elements E crees a 
l'etape precedente, selon la regie suivante : 

20 .1) W = 1 si la requete permet de recuperer des donnees d'image de 

meme qualite que I'image JPEG2000 memorisee, 

2) W = 0 sinon, 

3) C = Rpl si Q = basse, 

4) C = Rpm si Q = moyenne, 
25 5) C = Rph si Q = haute. 

L'etape E304 est suivie d'une etape E305 au cours de laqueile la 
machine client 2 calcule la priorite P de chacun des elements E selon I'equation 
suivante : 

P = K1/N avec K1 = PRIOMAX x Nmin = PRIOMIN x Nmax 
30 ou les valeurs PRIOMIN et PRIOMAX sont fixees au prealable, et Nmin et 
Nmax determinent la taille respectivement minimale et maximale des donnees 
image recuperees par une requete. La seule contrainte sur ces quatre valeurs 
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est que la relation PRIOMIN x Nmax = PRIOMAX x Nmin soit respectee de 
fagon a obtenir une priorite P comprise dans I'intervalle [PRIOMIN, PRIOMAX] 
et ce quelle que soit la requete. 

L'etape E305 est suivie d'une etape E306 au cours de laquelle la 
5 machine client 2 met a jour les requetes Rp comme decrit plus loin a I'aide de la 
figure 4. 

L'etape £306 est suivie d'une etape E307 au cours de laquelle la 

machine client 2 inclut les elements E correspondant aux requetes Rp ainsi 

formes dans la liste L 
10 L'etape E307 est suivie du test E308 au cours duquel la machine 

client 2 teste si le fichier SWF contient des requetes de la classe Ra. Si le test 

E308 est negatif, il est suivi d'une etape E312 decrite ulterieurement 

Si le test E308 est positif, la machine client 2 extrait ces requetesjdu 

fichier SWF et les stocke dans I'unite 22 de stockage de requetes (etape E3Q9). 
15 De plus, pour chacune de ces requetes, la machine client 2 cree un nouvel 

element E et initialise les variables W a 1 et C a Ra. 

L'etape E309 est suivie d'une etape E310 au cours de laquelle la 

machine client 2 calcule la priorite P de chacun des elements E ainsi crees 

selon les equations suivantes : 
20 P = PRIOMAX si temps courant = temps auquel les donnees doivent 

etre jouees, 

P = max(PRIOMIN,PRIOMAX/(temps auquel les donnees doivent 
etre jouees - temps courant)). 

Ainsi, revolution de la priorite suit revolution temporelle de 
25 I'animation. Certaines donnees, jugees initialement comme n'etant pas 
necessaires, le deviennent au cours du temps. Leur priorite augmente en 
consequence. 

L'etape E310 est suivie d'une etape E311 au cours de laquelle la 
machine client 2 inclut les elements des requetes Ra ainsi formes dans la liste 
30 L 

L J etape E311 est suivie de l'etape E312 d'envoi de requetes decrite 
plus loin a I'aide de la figure 5. 
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L'organigramme de la figure 4 illustre la mise a jour d'un jeu de 
requetes de la classe Rp. Comme on Fa explique en decrivant la figure 3, a 
chaque requete Rp est associe un element E de la liste L. 

Lors d'une etape E400, la machine client 2 initialise un compteur I a 
5 la position du premier element E du jeu de requetes a traiter. 

Cette etape est suivie d'un test E401 au cours duquel la machine 
client 2 teste si la priorite de i'eiement courant I est inferieure a PRIOMIN, c'est- 
a-dire si la quantite N des donnees image recuperees par cette requete est 
superieure a Nmax. Si le test E401 est negatif, il est suivi d'un test E407 decrit 
10 ulterieurement. 

Dans le cas contraire, le test E401 est suivi d'une etape E402 au 
cours de laquelle la requete est eclatee en autant de requetes que necessaire 
de fagon que chacune d'entre elles recupere une quantite de donnees 
inferieure ou egale a Nmax et que la totalite des donnees recuperees par ces 
15 nouvelles requetes corresponde a la quantite de donnees qui aurait ete 
recuperee par la requete initiale. A chacune de ces nouvelles requetes est 
associe un element E. 

L'etape E402 est suivie d'une etape E403 au cours de laquelle la 
machine client 2 initialise la variable W de chacun des nouveaux elements 
20 crees de fagon similaire a I'etape E304 de la figure 3. 

Les etapes suivantes E404 et E405 sont identiques respectivement 
aux etapes E305 et E307 de la figure 3. 

L'etape E405 est suivie d'une etape E406 au cours de laquelle la 
machine client 2 supprime I'eiement correspondant a la requete courante I et la 
25 requete courante I de i'unite 22 de stockage de requetes. 

Cette etape est suivie du test E407 au cours duquel la machine client 
2 teste si la priorite de Pelement courant I est superieure a PRIOMAX, c'est-a- 
dire si la quantite N des donnees image recuperees par cette requete est 
inferieure a Nmin. Si le test E407 est negatif, il est suivi d'un test E413 decrit 
30 ulterieurement. 

Dans le cas contraire, le test E407 est suivi d'une etape E408 au 
cours de laquelle la machine client 2 fusionne cette requete avec la requete 
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ayant la plus faible priorite (i.e. la plus grande valeur de N) de facon que la 
somme des priorites de ces deux requetes (respectivement la somme des 
quantites de donnees recuperees par les deux requetes) soit superieure 
(respectivement inferieure) a PRIOMIN (respectivement Nmax). 

5 L'etape E408 est suivie d'une etape E409 au cours de laquelle la 

machine client 2 initialise les variables W et C du nouvel element cree, de facon 
similaire a l'etape E304 de la figure 3. 

Les etapes suivantes E410 et E411 sont identiques respectivement 
aux etapes E305 et E307 de la figure 3. 

10 L'etape E411 est suivie d'une etape E412 au cours de laquelle la 

machine client 2 supprime les elements correspondant aux deux requetes 
fusionnees et les deux requetes de I'unite 22 de stockage de requetes. 

L'etape E412 est suivie du test E413 au cours duquel la machine 
client 2 teste si I'element courant est le dernier a traiter. Si le test E413 est 

1 5 positif, le processus de mise a jour s'arrete. 

Sinon, le test E413 est suivi d'une etape E414 qui considere 
I'element suivant (incrementation d'une unite du compteur I). L'etape E414 est 
suivie de l'etape E401 precedemment decrite. 

L'organigramme de la figure 5 illustre le fonctionnement du dispositif 

20 de la figure 1 une fois la phase d'initialisation de la figure 3 terminee. 

Tout d'abord, lors d'un test 500, la machine client 2 teste si 
Tutilisateur a demande une action particuliere sur l'animation a partir de Tunite 
24 de reception de requetes/ Seion un mode prefere de realisation de 
('invention, I'utilisateur a la possibility de demander trois actions sur I'image 

25 JPEG2000 : zoom, panoramique et changement de qualite. Des qu'une action 
est demandee, elle est stockee temporairement dans I'unite 22 de stockage de 
requetes. 

Si le test 500 est negatif, il est suivi d'un test E509 lors duquel la 
machine client 2 teste si des requetes de la classe Rp sont contenues dans la 
30 liste L. Si c'est le cas, le test E509 est suivi d'une etape E510 de mise a jour 
des variables W et C similaire a l'etape E304 de la figure 3. L'etape E510 est 
suivie d'un test E51 1 decrit ci-dessous. 
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Si le test E509 est negatif, il est suivi du test E511, au cours duquel 
la machine client 2 teste si des requetes de la classe Ra sont contenues dans 
la liste L Si ce n'est pas le cas, le test E511 est suivi d'une etape E513 decrite 
ulterieurement. Si c'est le cas, le test E511 est suivi d'une etape E512 au cours 
de laquelle la machine client 2 met a jour les requetes de la classe Ra selon la 
regie de l'etape E310 de la figure 3. 

L'etape E512 est suivie de l'etape E513 au cours de laquelle la 
machine client 2 trie les requetes de la liste L. Selon un mode prefere de 
realisation de invention, les requetes sont classees selon leurs priorites et 
independamment de leur classe, de la plus probable a la moins probable. 

L'etape E513 est suivie d'une etape E514 au cours de laquelle la 
machine client 2 envoie la requete la plus prioritaire parmi les requetes 
contenues dans la liste L au travers de I'unite 25 d'envoi de requetes. Une fois 
la requete envoyee, elle est supprimee, ainsi que I'element associe de I'unite 24 
de reception de requetes et de la liste L 

L'etape E514 est suivie du test E500 precedemment decrit. 
L'algorithme s'arrete a l'etape E514 a la demande de I'utiiisateur selon un mode 
prefere de realisation de I'invention. 

Si le test E500 est positif, c'est-a-dire si le client a demande une 
action particuliere sur I'animation, le test E500 est suivi d'une etape E501 au 
cours de laquelle la machine client 2 envoie la requete Ru. 

L'etape E501 est suivie d'un test E502 au cours duquel la machine 
client 2 teste si la liste L contient des elements de la classe Rp. Si ce n'est pas 
le cas, le test E502 est suivi de l'etape E513 precedemment decrite. 

Si la liste L contient des elements de la classe Rp, le test E502 est 
suivi d'une etape E503 au cours de laquelle la machine client 2 supprime des 
requetes Rp (et leurs elements associes) de la liste L et de I'unite 22 de 
stockage de requetes selon les donnees numeriques stockees dans I'unite 21 
de stockage de donnees. En effet, au fur et a mesure que des requetes sont 
envoyees, les donnees image regues sont stockees dans cette unite. De ce fait, 
pour eviter de demander plusieurs fois les memes donnees, certaines requetes 
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de la classe Rp deviennent obsoletes. Elles sont supprimees a cette etape a la 
fois de Punite 22 de stockage de requetes et de la liste L. 

L'etape E503 est suivie d'une etape E504 au cours de laquelle la 
machine client 2 cree de nouvelles requetes de la classe Rp (et de nouveaux 
5 elements E). En effet, selon les actions de Putiiisateur, certaines requetes de 
pre-chargement sont necessaires. Par exemple, si Pimage JPEG2000 est 
visualisee a basse qualite et que I'utiiisateur desire la visualiser a moyenne 
qualite, les requetes de pre-chargement pour anticiper un zoom ou un 
panoramique doivent permettent de recuperer des donnees image a qualite 
10 moyenne et non plus a basse qualite, de fagon a visualiser Pimage a une qualite 
constante. 

L'etape E504 est suivie d'une etape E505 au cours de laquelle la 
machine client 2 met a jour les variables W, c'est-a-dire valide ou non vies 
requetes, de fa?on similaire a l'etape E304 de la figure 3. . 
15 L'etape E505 est suivie d'une etape E506 au cours de laquelle, la 

machine client 2 met a jour les nouvelles requetes creees (s'il y a lieu) de fagon 
similaire a celle decrite par la figure 4. 

L'etape E506 est suivie d'une etape E507 au cours de laquelle la 
machine client 2 calcule les priorites de ces requetes Rp de fagon similair§ a 
20 l'etape E305 de la figure 3. 

L'etape E507 est suivie d'une etape E508 au cours de laquelle la 
machine client 2 inclut les nouvelles requetes Rp dans la liste L. L'etape E508 
est suivie de l'etape E513 precedemment decrite. 

II est a noter que dans le cas ou aucune nouvelle requete ne serait 
25 creee a l'etape E504, l'etape E504 est suivie de l'etape E513. 

En reference a la figure 6, est decrit un exemple d'appareil de 
communication programmable mettant en oeuvre Tinvention. 

Cet appareil comprend un dispositif de gestion des transmissions 
selon Pinvention, tel que celui represente sur la figure 1 et dont le 
30 fonctionnement est decrit en reference aux figures 3 a 5. L'appareil est 
connecte, de fagon identique au dispositif de la figure 1, a un appareil de 
communication jouant le role de machine serveur. 
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Selon le mode de realisation choisi et represente sur la figure 6, un 
appareil mettant en oeuvre I'invention est par exemple un micro-ordinateur 600 
ou une station de travail. 

L'appareil 600 comporte un bus de communication 602 auquel sont 

relies : 

- une unite centrale de traitement 603 (microprocesseur), qui exerce 
la fonction de Tunite 28 de commande de la figure 1 ; 

- une memoire morte 604, pouvant comporter les programmes 
"Progr et"Prog2 M ; 

- une memoire vive 606, comportant des registres 607 adaptes a 
enregistrer des variables et parametres crees et modifies au cours de 
Texecution des programmes precites, notamment, la liste L des elements et les 
listes des requetes Rp, Ra, les elements de cette liste L : W, C, P, I, PRIOMAX, 
PRIOMIN, mentionnes en reference aux figures precedentes ; 

- un ecran 608 permettant de visualiser des donnees et/ou de servir 
d'interface graphique avec I'utilisateur qui pourra interagir avec les programmes 
selon Tinvention, a I'aide d'un clavier 610 ou de tout autre moyen tel qu'un 
dispositif de pointage (non represente), comme par exemple une souris ou un 
crayon optique ; 

' - un disque dur 612 pouvant comporter les programmes "Progr et 
"Prog2" precites ; 

- un lecteur de disquettes 614 adapte a recevoir une disquette 616 
et a y lire ou a y ecrire des donnees traitees ou a traiter selon Tinvention ; 

- une interface de communication 618 reliee a un reseau de 
communication 620, par exemple le reseau Internet, ['interface etant apte a 
transmettre et a recevoir des donnees ; 

- une camera numerique 601, ou tout autre dispositif d'acquisition 

d'images. 

Dans !e cas de donnees audio, l'appareil comprend en outre une 
carte d'entrees/sorties reliee a un microphone (non representes). 

Le bus de communication 602 permet la communication et 
I'interoperabilite entre les differents elements inclus dans le micro-ordinateur 
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600 ou relies a lui. La representation du bus n'est pas limitative et, notamment, 
I'unite centrale est susceptible de communiquer des instructions a tout element 
du micro-ordinateur 600 directement ou par Pintermediaire d'un autre element 
du micro-ordinateur 600. 
5 Le code executable de chaque programme permettant a t'appareil 

programmable de mettre en oeuvre les processus de traitement des requetes 
selon ['invention, peut etre stocke par exemple sur le disque dur 612 ou en 
memoire morte 604. 

Selon une variante, la disquette 616 peut contenir des donnees ainsi 

10 que le code executable des programmes precites qui, une fois lu par I'appareil 
600, sera stocke sur le disque dur 612. 

En seconde variante, le code executable des programmes pourra 
etre regu par I'intermediaire du reseau de communication 620, via interface 
618, pour etre stocke comme decrit precedemment. 

15 Les disquettes peuvent etre remplacees par tout support 

d'information tel que, par exemple, un disque compact (CD-ROM) ou une carte 
memoire. De maniere generate, un moyen de stockage d'information, lisible par 
un ordinateur ou par un microprocesseur, integre ou non a I'appareil, 
eventuellement amovible, est adapte a memoriser un ou piusieurs programmes 

20 dont I'execution permet la mise en ceuvre du procede selon I'invention. 

De maniere plus generale, le ou les programmes pourront etre 
charges, dans un des moyens de stockage de I'appareil 600 avant d'etre 
executes. 

L'unite centrale 603 va commander et diriger ('execution des 
25 instructions ou portions de code logiciel du ou des programmes selon 
I'invention, instructions qui sont stockees sur le disque dur 612 ou dans la 
memoire morte 604 ou bien dans les autres elements de stockage precites. 
Lors de la mise sous tension, le ou les programmes qui sont stockes dans une 
memoire non volatile, par exemple le disque dur 612 ou la memoire ROM 604, 
30 sont transferes dans la memoire vive RAM 606 qui contient alors le code 
executable du ou des programmes selon I'invention, ainsi que des registres 
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pour memoriser les variables et parametres necessaires a la mise en oeuvre de 
I'invention. 

II convient de noter que I'appareil de communication comportant le 
dispositif selon I'invention peut egalement etre un appareil programme. 

Cet appareil contient alors le code du ou des programmes 
informatiques, par exemple fige dans un circuit integre dedie (ASIC, en anglais 
"Application Specific Integrated Circuit'). 
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REVINDICATIONS 

1. Procede de gestion de requetes d'au moins deux classes 
distinctes, portant sur des donnees multimedia, echangees par un appareil de - 

5 communication (2) et au moins une source de donnees (1) connectes par 
('intermediate d'un reseau de communication (3), caracterise en ce que ledit 
procede comporte des etapes, effectuees au niveau de I'appareil de 
communication (2), de : 

- validation (E505, E510) d'au moins une requete d'au moins une 
10 premiere classe de requetes, la validation tenant compte des donnees 

multimedia regues a partir d'au moins une deuxieme classe de requetes ; et 

- affectation dynamique d'une priorite (E512, E507) a chacune des 
requetes validees, suivant des caracteristiques desdites requetes validees. < . 

2. Procede selon la revendication 1, caracterise en ce qu'il comporte 
15 en outre une etape de decision (E513, E514) quant a la transmission d'au 

moins une requete validee, en fonction de la priorite affectee a ladite requete. 

3. Procede selon la revendication 1 ou 2, caracterise en ce qu'il 
comporte en outre une etape de mise a jour (E503, E504, E506) des requetes 
d'au moins une premiere classe, la mise a jour tenant compte des donnees 

20 multimedia regues a partir d'au moins une requete d'au moins une deuxieme 
classe. 

4. Procede selon la revendication 1, 2 ou 3, caracterise en ce que 
ledit appareil de communication (2) et ladite source de donnees (1) sont 
connectes par une connexion de type HTTP. 

25 5. Procede selon Tune quelconque des revendications precedentes, 

caracterise en ce que les donnees sont des animations Flash et/ou des 
donnees d'images comprimees suivant la norme JPEG2000. 

6. Procede selon Tune quelconque des revendications precedentes, 
caracterise en ce que lesdites requetes sont associees a ('animation d'un objet 

30 (Ra) et/ou a la realisation d'un zoom ou d'un panoramique ou d'un changement 
de qualite sur une image (Rp) et/ou a des interactions entre un utilisateur et une 
animation (Ru). 
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7. Dispositif de gestion de requetes d'au moins deux classes 
distinctes, portant sur des donnees multimedia, echangees par un appareil de 
communication (2) et au moins une source de donnees (1) connectes par 
Pintermediaire d'un reseau de communication (3), caracterise en ce que ledit 

5 dispositif comporte : 

- des moyens de validation d'au moins une requete d'au moins une 
premiere classe de requetes, la validation tenant compte des donnees 
multimedia regues a partir d'au moins une deuxieme classe de requetes ; et 

- des moyens d'affectation dynamique d'une priorite a chacune des 
10 requetes validees, suivant des caracteristiques desdites requetes validees. 

8. Dispositif selon la revendication precedente, caracterise en ce qu'il 
comporte en outre des moyens de decision quant a la transmission d'au moins 
une requete validee, en fonction de la priorite affectee a ladite requete. 

9. Dispositif selon la revendication 7 ou 8, caracterise en ce qu'il 
15 comporte en outre des moyens de mise a jour des requetes d'au moins une 

premiere classe, la mise a jour tenant compte des donnees multimedia regues a 
partir d'au moins une requete d'au moins une deuxieme classe. 

10. Dispositif selon la revendication 7, 8 ou 9, caracterise en ce que 
ledit appareil de communication (2) et ladite source de donnees (1) sont 

20 connectes par une connexion de type HTTP. 

11. Dispositif selon Tune quelconque des revendications 7 a 10, 
caracterise en ce que les donnees sont des animations Flash et/ou des 
donnees d'images comprimees suivant la norme JPEG2000. 

12. Dispositif selon Tune quelconque des revendications 7 a 11, 
25 caracterise en ce que lesdites requetes sont associees a ['animation d'un objet 

(Ra) et/ou a la realisation d'un zoom ou d'un panoramique ou d'un changement 
de qualite sur une image (Rp) et/ou a des interactions entre un utilisateur et une 
animation (Ru). 

13. Appareil de communication, caracterise en ce qu'il comporte un 
30 dispositif selon Tune quelconque des revendications 7 a 12. 



1er depot 



1/7 



21 



Unite de stockage 
de donnees 
numeriques 



22 



^ Unite de stockage 
de requetes 



23 



Unite de traitement 
de donnees 
numeriques 



z 



28 



Unite 
de 

Commande 



Unite de reception de 
requetes 



Unite d' envoi de 
requetes 



Unite de gestion de 
requetes 



Unite de reception de 
donnees numeriques 



24 



25 

V 



26 



27 




Unite de reception de requetes 



11 



Unite d 5 envoi de 
donnees numeriques 



UC 



Unite de traitement 
de requetes 



Unite de stockage 

de donnees numeriques 



12 



13 



FIG. 1 




204 
_i_ 



fichier SWF 



205 



Initialisation animation 


Image basse resolution 


Ra 


Rpl 



FIG. 2a 



1 er depot 



3/7 



206 






k. 




<4 














► 


207 - 




r 





panoramique 




original Zoom (x2) 

zoom 



FIG. 2b 



1er depot 



4/7 



FIG. 3 



E300 





Reception du fichier SWF 










f 




E301 


Extraction et stockage des donnees image 




non ^ — 


r E302 






Requetes Rp ? 



oui 



Extraction et stockage de Rp 



E303 



E304 



Initialisation de W et C 



E305 



Calcul des priorites pour Rp 



Mise a jour de Rp 



E306 



E307 



Inclusion de Rp dans L 



non 




E308 



Requetes Ra ? 




oui 



Extraction et stockage de Ra 



Calcul des priorites pour Ra 



E309 



E310 



E311 



Inclusion de Ra dans L 



Envoi de requetes 



E312 



1er depot 



E414 



1=1+1 



5/7 



1=0 



E400 



E401 



P[I] < PRIOMIN ? 
oui 




non 



Eclatement de la requete I 



E402 



Initialisation de W 



E403 



E404 



Calcul des priorites pour Rp 



Inclusion de Rp dans L 



Suppression de la requete I 



non 



P[I] > PRIOMAX ? 

Oui 




E405 

E406 
E407 



E408 



Fusion de la requete I avec la requete K 




V 


E409 




Initialisation de W et C 





Calcul de la priorite 



Inclusion de 1' element dans L 



E410 
411 

E412 



Suppression des requetes I et K 



non 




E413 
: — ► fin 
oui FIG. 4 



1 er depot 



6/7 



E500 




E501 





Envoi de Ru 


M 


I ► 





E502 



-W Requetes 




non 



E503 oui 



non 



Suppression de Rp 



E510 



3 


oui 

r 


Mise a jour de W et C 




E511 



non 




Requetes Ra ? y+ 



E504 

Vi 



Creation nouvelles requetes 



E505 



Mise a jour de W 



E506 



Mise a jour de Rp 



oui 



E512 



Mise a jour des priorites 



E507 



E508 



Calcui des priorites 



Inclusion de Rp dans L 



Tri de la liste L 



Envoi de la requete 
la plus prioritaire 



E513 



E514 



FIG. 5 



1er depot 



111 



f 



603 



ROM 



Progl,Prog2 



CPU 



L 



608 



Ecran 



610 



Clavier 



612 



Disque dur 



Progl,Prog2 



614 



Lecteur de 
disquettes 



604 



606 / 



z 



RAM 



Interface de 
communication 



8 



602 



616 



j Disquette 



Camera numerique 



RAM 

elementsdeliste: W,C,P 
indicede boucle: I 
liste:L,Rp,Ra 



~7 

607 



600 



Reseau 



T 



620 



FIG. 6 



601 




a 1NSTITUT 

NATIONAL OE 
LA PROPRIETE 
INDUSTRIELLE 



recue le 26/03/03 

BREVET DiNVENTION 
CERTIFICAT D UTILITE 

Code de la propriete intellectuelle - tivre VI 



N° 11235*03 



DEPARTEMENT DES BREVETS 

26 bis, rue de Saint Petersbourg 
75800 Paris Cedex 08 

Telephone : 33 (1) 53 04 53 04 Tetecopie : 33 (1) 42 94 86 54 



DESIGNATION D'INVENTEUR(S) Page N° A I A 

(A fournir dans le cas ou les demandeurs et 

les inventeurs ne sont pas les memes personnes) 



I Vos references pour ce dossier (j'acuhaiif) 



| N° D'ENREGISTREMENT NATIONAL 



Cet imprime est a remplir lisiblementj [encre noire 

BIF023415/MR/M^~ 



08 113 W/ 270601 



XX 



I TITRE DE ^INVENTION (200 caracteres ou espaces maximum) 



Precede et dispositif de gestion de requetes dans une architecture du type client- serveur 



LE(S) DEMANDEUR(S) : 

" IcANON KABUSHIKJ KAISHA 



DESIGNE(NT) EN TANT QU'INVENTEUR(S) 



Nom 



Prenoms 



Adresse 



Rue 



LABELLE 



Lilian 



18, rue de la Mettne, 



Code postal et ville 



Societe d'apparte nance (facultatif) 



| ¥1 Nom 



Prenoms 



Adresse 



Rue 



Code postal et ville 



Societe d'appartenance (facultatif) 



122100 



J L 



"STSAMSONSUR RANCK, France 



J I L 



Prenoms 



Adresse 



Rue 



Code postal et ville 



i » i » i 1 



Societe d'appartenance (facultatif) 



S'il y a plus de trois inventeurs, 



^H^lu^urs formulair es. Indiquez en hautldroite le N° de la page suiyi du nombre de pages. 



DATE ET SIGNATURE(S) 
DU (DES) DEMANDEUR(S) 
OU DU MANDATAIRE 
(Nom et qualite du signataire) 



Le 14fevrier2003 

Muriel ROSENBERG N°98.0508 

RINUY, SANTARELLI 




La loi n-78-17 du 6 janvier 1978 relative a I'informatique, aux fichiers et aux libertes s'applique aux reponses faites a ce formulaire. 
Elie garantit un droit d'acces et de rectification pour les donnees vous concernant aupres de I INPI. 



